#syscalls #low-level #operating-systems #kernel #calls #abi

cloudabi

Low level interface to CloudABI. Contains all syscalls and related types.

4 releases

0.1.0 Dec 22, 2019
0.0.3 Jan 10, 2018
0.0.2 Jan 4, 2018
0.0.1 Dec 24, 2017

#195 in Operating systems

Download history 40107/week @ 2023-12-06 37590/week @ 2023-12-13 30539/week @ 2023-12-20 25300/week @ 2023-12-27 37820/week @ 2024-01-03 38144/week @ 2024-01-10 37328/week @ 2024-01-17 39956/week @ 2024-01-24 36677/week @ 2024-01-31 41374/week @ 2024-02-07 35248/week @ 2024-02-14 35624/week @ 2024-02-21 38381/week @ 2024-02-28 36728/week @ 2024-03-06 40009/week @ 2024-03-13 29895/week @ 2024-03-20

151,951 downloads per month

BSD-2-Clause

105KB
1.5K SLoC

PLEASE NOTE: This entire crate including this documentation is automatically generated from cloudabi.txt

Nuxi CloudABI

CloudABI is what you get if you take POSIX, add capability-based security, and remove everything that's incompatible with that. The result is a minimal ABI consisting of only 49 syscalls.

CloudABI doesn't have its own kernel, but instead is implemented in existing kernels: FreeBSD has CloudABI support for x86-64 and arm64, and a patch-set for NetBSD and a patch-set for Linux are available as well. This means that CloudABI binaries can be executed on different operating systems, without any modification.

Capability-Based Security

Capability-based security means that processes can only perform actions that have no global impact. Processes cannot open files by their absolute path, cannot open network connections, and cannot observe global system state such as the process table.

The capabilities of a process are fully determined by its set of open file descriptors (fds). For example, files can only be opened if the process already has a file descriptor to a directory the file is in.

Unlike in POSIX, where processes are normally started with file descriptors 0, 1, and 2 reserved for standard input, output, and error, CloudABI does not reserve any file descriptor numbers for specific purposes.

In CloudABI, a process depends on its parent process to launch it with the right set of resources, since the process will not be able to open any new resources. For example, a simple static web server would need to be started with a file descriptor to a TCP listener, and a file descriptor to the directory for which to serve files. The web server will then be unable to do anything other than reading files in that directory, and process incoming network connections.

So, unknown CloudABI binaries can safely be executed without the need for containers, virtual machines, or other sandboxing technologies.

Watch Ed Schouten's Talk at 32C3 for more information about what capability-based security for UNIX means.

Cloudlibc

Cloudlibc is an implementation of the C standard library, without all CloudABI-incompatible functions. For example, Cloudlibc does not have printf, but does have fprintf. It does not have open, but does have openat.

CloudABI-Ports

CloudABI-Ports is a collection of ports of commonly used libraries and applications to CloudABI. It contains software such as zlib, libpng, boost, memcached, and much more. The software is patched to not depend on any global state, such as files in /etc or /dev, using open(), etc.

Using CloudABI

Instructions for using CloudABI (including kernel modules/patches, toolchain, and ports) are available for several operating systems:

Specification of the ABI

The entire ABI is specified in a file called cloudabi.txt, from which all headers and documentation (including the one you're reading now) is generated.

Dependencies

~88KB