nuxinl / cloudabi Goto Github PK

For the last few days, everyone has been talking about the new branch prediction/cache/timing attacks. I've been thinking, maybe this is a good opportunity for CloudABI?

• Time Stamp Counter access can be disabled — is it getting disabled in CloudABI applications?
• browsers are lowering timer precision — I think typical web servers also do not need high accuracy timers, so maybe CloudABI should allow the user to say something like max_timer_precision: 1ms in the YAML file to limit the maximum resolution of cloudabi_sys_clock_time_get(). Also something like randomize_clocks: true to make cloudabi_sys_clock_time_get() report fuzzy time.
• maybe KPTI-style mitigations should always apply for CloudABI binaries, regardless of whether they're enabled globally in the system (like with Linux's boot flag)?

(I realize the project is unmaintained, but I'll mention this anyway.)

CloudABI claims that programs that use it have no effect on global resources, so that they can safely be run without a container, VM, or other enclosure mechanism. However, fork bombs are still possible. (Tl;dr: a process forks, and then each child process forks, and then ...)

Is there a way to get user-friendly messages (static str or other) from errno numbers? I can't see anything except to refer to the table in cloudabi.txt:209.

For comparison, see from_raw_os_error which uses sys::os::error_string, which uses strerror_r internally. It looks like CloudABI error codes don't match up with POSIX error codes so will you provide an equivalent?

What’s the difference between the websites? As a newbie it’s a tad confusing to have to navigate to both for info, and that’s not counting the GitHub source website.

I'm assuming that at some point a syscall might need to be added, and one might need preprocessor definitions to understand which version of CloudABI is available.

Can the ABI version be determined by a preprocessor definition?

Right now all I am finding is __CloudABI__ which is set to the value of 1:

$ /usr/bin/x86_64-unknown-cloudabi-cc -dM -E - < /dev/null | grep -i abi
#define __CloudABI__ 1
...

I understand that project is not maintained now, but there are too many links which were used and now redirected to nowhere. In particular, it's hard to understand to new user now e.g. how to obtain runtime packages. Probably they could be built manually given instructions from where and how?

I like the idea of CloudABI, and WASM is not substitute for it, so it would be great if it still be usable at least in "frozen" state, so new user could appear, and sometimes hopefully new maintainers!

The right rights.fd_datasync includes "If rights.file_open is set, includes the right to invoke file_open with fdflags.dsync." However, if one has the rights.fd_stat_put_flags right, it would appear one could invoke sys_fd_stat_put_flags with fdsflags.flags to set the fdflags.dsync flag, which would be a way to obtain a file descriptor with fdflags.dsync without having rights.fd_datasync.

Consequently, if one wishes to withhold the ability to open files with fdflags.dsync set, clearing the rights.fd_datasync right might seem sufficient, but isn't: one must also clear the rights.fd_stat_put_flags right as well. It would seem more consistent to make sys_fd_stat_put_flags require rights.fd_datasync for setting fdflags.dsync.

Similar considerations apply to rights.fd_sync, fdflags.rsync, and fdflags.dsync.

https://nuxi.nl/cloudabi/freebsd/

'''
[user@freebsd ~]$ sudo pkg install cloudabi-utils
Password:
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating CloudABI repository catalogue...
CloudABI repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'cloudabi-utils' have been found in the repositories
'''

As an engineer, I want to see some basic benchmarks for key performance indicators, so that I have more information when deciding to use CloudABI versus competing tools for sandboxing.

For example, I am interested in seeing how many queries per second the same C/C++ Web server application can provide depending on whether it runs natively (libc) vs. cloudabi-run vs. cloudabi-run -e vs. Docker.

As long as we’re running arbitrary binaries with security in mind, we may as well implement our libc in Rust. This reduces the risk of buffer overflow escapes from our sandbox.

Fortunately, Rust is able to output C-compatible object files. So while cloudlibc could be reimplemented in Rust, there is no technical requirement that user applications be written in Rust; they can continue using a typical C FFI.

I think this should be done with cloudlibc proper, as well as the cloudabi runtime and any dependencies as well, such as the yaml arg parser.

@m-ou-se Thank you for publishing crates to integrate Rust with CloudABI! Could the source for the argdata and cloudabi crates be posted as well? Not sure if these are generated directly from the C or what.

By the way, would love to see the argdata crate build in Rust stable. Is there a way to get this to work without depending on the nightly try_from feature?

The subscription.clock.identifier field appears to be unused.

It appears to have become unused when the identifier field was removed from event_t.

Obviously, removing this field would be an ABI change, so I don't know if it's worth it, but it would be useful to document it if not.

clock_time_get has a precision parameter, which has this documentation:

The maximum lag (exclusive) that the returned
time value may have, compared to its actual
value.

The CloudABI implementations on FreeBSD, Linux, and the emulator don't seem to use this parameter.

One hypothetical use for it might be to allow implementations to return an error in case they can't provide the requested level of precision, however in cloudlibc, clock_time_get's return value is usually ignored. And applications can use clock_res_get to learn about the precision they're getting from clock_time_get.

Is there an expected future use for the precision parameter?

I think file descriptors tend to use signed 32-bit integers, whereas the Rust crate uses unsigned. How important is it to expand the potential open files that wide, versus the trade-off of losing some type compatibility between libc vs. CloudABI?

This subtle difference makes it a bit harder to write polyglot programs that can target libc and CloudABI, depending on the toolchain applied.

Could the CloudABI runtime support an option to enforce W^X, in order to reduce the attack surface further? This would minimize the risk of escaping out of the CloudABI runtime into the host.

BOINC is a distributed computing platform currently prioritizing jobs for evaluating COVID-19 vaccines.

https://boinc.bakerlab.org/

macOS, Windows, Linux desktop, Android, and Docker currently supported.

This line should likely be changed to use mem::zeroed() if I'm following correctly that these are C-like structs that are being initialized.

It is not currently defined to perform the reference and field access on the uninitialized memory too, whereas with zeroed this should be fine (at least as I understand it, though I cannot be 100% certain, as some of these details are still in flux).

Hello. Your CloudABI need to be complemented by something. We lack object-oriented shell for it.
What I mean under object-oriented shell? Now the shells work with 3 binary streams and allow only their redirection. It is not fine: what if I need to pass a resource from one process to another? What if I need to pass multiple resources, for example multiple streams? In the case of multiple streams fifo can help, but in case of resources of other types it won't.

The proposial is to use programms as functions with variable number of arguments.
1 Each programm binary has a metadata block in it describing its command line format.
2 The shell reads that metadata block and validates vommand line before executing
3 when executing the shell passes arguments to a programm
4 The arguments are not text strings, they are objects of standardized types. For first time I propose to have the following types : string, number, input stream, output stream, input-output stream, network, error and void.
5 A programm has one return type, it can return either its return type or error.
6 A programm can either return its type and stop or return its type and daemonize itself. In the case it daemonizes itself it can be used by another program through the returned object.
7 Arguments types can be implicitly converted, for example strings can be converted into file descriptors which are iostreams.

Most devices are ran at RTOS, and that's great to unify the RTOS family with linux/unix.