Over the last week or so I've been doing a _lot_ of improvements to [Olin][olin] in order to make it ready to be the kernel for the minimum viable product of [wasmcloud][wasmcloud-hello-world]. Here's an overview of the big things that have happened from version [0.1.1][olin-0.1.1] to version [0.4.0][olin-0.4.0].
[Olin][olin] is a userspace kernel designed for multi-tenant secure computing. It provides isolation via WebAssembly to limit the attack scope of malicious user input, resource accounting via its runtime statistics, and a familiar Unix-like API. It is the core that you can build a functions as a service platform on top of.
For an example of Olin in action, please click [here][olin-example].
[olin]: https://github.com/Xe/olin
[olin-example]: https://home.cetacean.club/cwagi
As Olin is just a kernel, it needs some work in order to really shine as a true child of the cloud. That work is incoming during the next weeks and months.
## Announcements
Here is what has been done since the [last Olin post][last-olin-post]:
For the moment, I am deprecating support for [Go][golang] in `GOOS=js GOARCH=wasm`. The ABI for the Go compiler in this mode is too unstable for me right now. If other people want to fix [`abi/wasmgo`][abi-wasmgo] to support Go 1.13 and newer, I would be _very_ welcome to the patches.
Early on in the experiments that make up Olin, I have made a mistake in my fundamental understanding of how operating systems run programs. I thought that the main function would return the exit code of the program. This is not the case. There is a small shim that wraps the main function of your language and passes the result of it to `exit()`. Olin now copies this behavior. In order to return a value to the Olin runtime, you can either call `runtime_exit()` or return from the `_start()` function to exit with 0. Many thanks to Andrew Kelly for helping me realize this error.
This behavior is copied in the [Olin rust package][olin-rust-entrypoint], which now has a fancy macro to automate the creation of the `_start()` function.
I am waiting on Zig to release a new nightly version in order to enable it, but the [bring-your-own-OS package][bring-your-own-os] support in Zig means that the Zig standard library is starting to be exposed into Olin programs. Here's an example based on the [example program][zig-example-program]:
$ cat cwa.cfg | sudo tee /proc/sys/fs/binfmt_misc/register
```
Then you can run Olin programs without calling `cwa`:
```console
$ ./olinfetch.wasm
```
## Features
### Policy Support
Olin now has a declarative policy engine for accessing external resources. This is inspired from OpenBSD `pledge()` and macOS sandboxing. These policies allow setting the following attributes:
* Resources an Olin program can access, matched by regular expressions
* Resources an Olin program CANNOT access, matched by regular expressions
* The maximum amount of memory an Olin program can use
* The maximum number of WebAssembly instructions a WebAssembly program can execute
Here's an example policy file intended to help with relaying webhooks:
```
## This is an example policy, the ## signifies this line is a comment.
## These are the URL patterns that this handler can open:
allow (
^https://tulpa.dev
^https://discordapp.com/api/webhooks/
^random://$
)
## These are the URL patterns that this handler cannot open:
disallow (
^https://tulpa.dev/admin.*$
)
## This is the ram limit in pages (64k each):
ram-page-limit 128
## This is the gas limit in instructions:
gas-limit 1048576
```
This would allow a WebAssembly program to open a HTTP socket to https://tulpa.dev (my git server) and Discord, but disallows any administrative API calls to my git server. It also allows the Olin program to use up to 128 pages of memory (about 8MB, which goes surprisingly far) and 1.04 million instructions. If the handler tries to open any resource that is not explicitly allowed, it is killed. If the handler tries to open a resource that is explicitly forbidden, it is killed. If the handler uses too much ram or too many instructions, it is killed.
This allows handlers to safely process user controlled input and even use that as part of the call to the open function.
When policies are violated, the error thrown is a [vibe check failure][vibe-check]:
Along with making `_start()` the entrypoint, there comes a new problem: exiting. I fixed this by adding a [`runtime_exit()`][runtime-exit] system call in Olin. When you call this function with the status code you want to return, execution of the Olin program instantly ends, uncleanly stopping everything and closing all files the program has open. This is similar to Linux's `exit()` system call.
It's probably best to save this call for cases where the program _really can't/shouldn't_ continue executing, like for panic handlers.
### Generic CGI Support
Previously there was a half-baked idea I called cwagi in Olin's codebase. The idea was to emulate part of how CGI worked in order to let Olin programs handle HTTP easily. I realize this was a mistake, so now it [just supports normal CGI][cgi-patch], conforming to [RFC 3875][rfc3875].
One of the more common errors in operating systems is the "end of file" error. It is raised when a file has no more data in it. Olin didn't have this, but [now it does][eof-patch].
