Version 0.1.0

At this point it should be sensible to call this an "operating system". Most of the basic functionality is there.

Syscalls

The following system calls are supported:

i32 sys$read(i32 fd, u8 *buffer, usize count);
i32 sys$write(i32 fd, const u8 *buffer, usize count);
i32 sys$open(const char *pathname, u32 flags, u32 mode);
i32 sys$close(i32 fd);
i32 sys$fstat(i32 fd, UserlandFileInfo *statbuf);
i32 sys$wait(i32 *status);
i32 sys$exit(i32 status);
i32 sys$chdir(const char *pathname);
i32 sys$get_working_directory(u8 *buffer, usize *size);

i32 sys$posix_spawn(
    i32 *pid,
    const char *pathname,
    const UserlandSpawnFileActions *file_actions,
    const UserlandSpawnAttributes *attrp,
    char **argv,
    char **envp);

However, most of the functionality is only mocked. Notice that fork() is not supported because a Cortex-M0+ does not posses an MMU. Originally, vfork() was supported but posix_spawn() is simply better.

Acceptance Test

The following script can be executed on the system to illustrate it's capability:

echo foo bar
stat /example.txt
ls
cd /bin
ls ../dev
cat /example.txt
touch foo
cat foo
Editor.elf
% 0a
% bar
% .
% w foo
% q
cat foo
Shell.elf
ls

Isolation and Security

Since this is (more or less) a microcontroller, only very basic protection is possible, and currently there is not even much done for that.

Secure:

• User code is executed unprivileged.

• There is basic memory isolation, the user code can not write into kernel memory directly.

Insecure:

• Currently, there is a "handler trampoline" in place that simply executes a provided function pointer without checking anything.

• The user code can read the kernel code, which is problematic but acceptable.

• Bugs, lots of bugs.